Storm, Spark streaming, Flink中的backpressure机制比较。


backpressure是分布式流处理系统中一种有效的流量控制手段，为了防止负载过大，计算瓶颈等对整个系统带来的影响。backpressure基本上是每个流处理系统都应该考虑的一种流量控制手段。流量控制的方法有很多种，有兴趣的可以去看看网络中是怎么控制流量的。分布式流其实和网络流的本质是一样的。



本文先分别讨论各个系统的backpressure机制，然后再总结三者的异同。

Storm

storm的backpressure功能流程如下：


在worker中会有一个backpressure线程，实时的监控executor的receive queue或者worker的transfer queue的状态，一旦发现某一queue中的数据量超过一个阈值（由 backpressure.disruptor.high.watermark 配置，默认为0.9），即触发backpressure，此时backpressure线程会将这当前topology的信息写入zookeeper，watcher检测到zookeeper中的数据变化，则立马通知所有worker进入backpressure状态，上游spout停止发送数据,直到queue中的数据量低于一个阈值（由 backpressure.disruptor.low.watermark 配置，默认为0.4）。所有worker退出backpressure状态，spout正常发送数据。


executor.clj中代码段：
1
2
3
4
(if (and (not (.isFull transfer-queue))
                     (not throttle-on)
                     (not reached-max-spout-pending))
                 (fast-list-iter [^ISpout spout spouts] (.nextTuple spout))))


不了解disruptor queue在storm中的使用的可以参考：Understanding the Parallelism of a Storm Topology



storm中的backpressure还是相当暴力的。这样子其实整个系统都处在一个不稳定的状态，堵住了马上就不发送任何数据进来，直到疏通了，开始发送，然后慢慢堵住，直到触发backpressure。

storm backpressure具体内容参考：storm-886

Flink是新一代的流处理系统，其backpressure的实现方式相比于storm有很大的区别。其不再借助zookeeper或者其他的外部组件来实现backpressure。而是在其内部数据传输时用一种类似阻塞队列的方式很合理，很漂亮的实现了这一功能。


具体流程已经有人写了很好的博文了,我就不再多次一举了。

Spark Streaming

待研究。